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1. INTRODUCTION 
1.1 The Manual 

This manual describes the Design Procedure Language (DPL) for LSI design. 
DPL creates and maintains a representation of a design in a hierarchically organized, 
object-oriented LISP data-base. Designing in DPL involves writing programs (Design 
Procedures) that construct and manipulate descriptions of a project. The programs 
use a call-by-keyword syntax and may be entered interactively or written by other 
programs. DPL is the layout language for the LISP-based Integrated Circuit design 
system (LISPIC) being developed at the Artificial Intelligence Laboratory at MIT. The 
LISPIC design environment will combine a large set of design tools that interact 
through a common data-base. 

This manual is for prospective users of the DPL and covers the information 
necessary to design a project with the language. The philosophy and goals of the 
LISPIC system as well as some details of the DPL data-base are also discussed. The 
implementation of the language is not discussed here except for those details that are 
felt to be instructive when attempting to understand the language. The manual is 
organized as follows: 

The introduction describes the key features of the LISPIC system, the data-base 
and DPL. 

Chapter 2 contains some introductory examples of the use of DPL. The 
examples consists of definitions of several cells and pictures of the cells. 

Chapter 3 presents an overview of the DPL data-base. Here we discuss abstract 
structures used to represent designs. 

Chapters 4 through 8 present DPL itself. The functions and forms most useful 
for using DPL when designing a project are presented and explained. The material in 
these chapters constitutes all of the information necessary to use the language. 

Chapter 9 discusses how DPL "looks" to the user. It presents interaction details 
as well as functions for translating between DPL and CIF. 

Chapter 10 presents a fairly hefty example which exercises many of the features 
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of the language. The example also demonstrates the design style which DPL 
supports. 

Chapter 11 is a library containing the definitions of objects available in the basic 
DPL system. This chapter is useful both as a set of examples of the use of DPL and as 
a reference for designing. 

Chapter 12 is a glossary of DPL functions and variables. The syntax and usage 
of functions are summarized. This is where we explain how all the functions evaluate 
their arguments. The most useful DPL functions will have been met earlier in the 
manual. The glossary also contains functions which are less useful or more "low 
level" then the functions explained in the body of the manual. 

1,2 Designing With DPL 

VLSI design is complicated. A large IC design may contain several thousand or 
more pieces of material. Designers think of their designs not in their full complication 
but rather as collections of of parts which may be further decomposed into other 
/-^ parts. Such a hierarchical viewpoint both expresses the designer's understanding of 

his design and economizes his thinking about it. Unnecessary detail is suppressed so 
that the gate, module, subsystem or system of interest may be dealt with. 

A set of design tools should be able to represent the design in as much the same 
way the designer does as possible. Thus the basis of a set of design tools should be a 
data-base representation of designs that is flexible, extensible and hierarchical. The 
goal of the LISP-based Integrated Circuit (LISPIC) design project is to produce a 
design system consisting of a large number of design tools -- simulators, design 
verifiers, routers etc. •■ integrated with one another through a common data 
representation. 

The Design Procedure Language (DPL) is a collection of LISP functions that 
construct and manipulate a hierarchically organized object-oriented data-base. DPL 
is intended to be a user language -- it can actually be used by a human to build 
projects. DPL may also be used by programs such as PLA generators, routers, and 
node-extractors. Since it is embedded in LISP, DPL inherits the power of a full 
programming language. LISP programs can be written that call DPL functions and 
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vice-versa. 

The LISPIC system is illustrated in Figure 1. The LISP-based data base is 
manipulated by the DPL language. Other programs and systems communicate with 
the data-base through DPL. The other systems may communicate and cooperate with 
each other through this common representation. (Note: Not all of the systems 
pictured are available yet.) 

Using DPL consists of designing a project by specifying a procedure that will 
build it. This is the reason for the name "Design Procedure Language". A design 
procedure constructs a data-structure which holds a description of a design. The 
descriptions may include procedures for further manipulation of the data-base. At 
some point the designer will want to actually construct a physical implementation of 
the project, but for most of the design process that is not necessary. What is 
necessary is the construction and maintenance of a structure that represents the 
design. Since much in a design description is procedural, a description can help to 
build itself. Such procedural descriptions also allow the DPL data-base to be modified 
by other programs. 

We should point out that the need to do this sort of thing is the reason why the 
system is implemented in LISP. More than any other programming language, LISP 
easily handles arbitrary structures that may contain procedural parts and may even be 
able to build themselves. The simple syntax of LISP allows programs to write 
programs easily, and the interpreter allows a "real-time" interaction between the 
designer and the language. 

Parameters to DPL design procedures use call-by-keyword syntax. The 
parameters may be assigned default values. Constraints among the parameters may 
be specified by the designer. Parts and parameters of objects may be named and the 
named information may be accessed by functions which follow path descriptions and 
transform objects. 

The DPL design process involves the following stages: The designer specifies 
procedures for constructing pieces of the design. These pieces are then used to build 
more complicated representations. The procedures may refer to information stored in 
the structure earlier. Mistakes may be corrected and changes implemented by 
making use of information in the existing structure. The final design is a complicated 
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yet organized hierarchical structure which may be used to produce mask 
specifications. 

1.3 Credits 

DPL was written by Gerald Jay Sussman, Howard Shrobe, Neil Mayle, and John 
Batali. The language is based on two earlier IC layout languages, one by Jack 
Holloway and Sussman, the other by Shrobe. Ron Rivest, Daniel Weise, Anne 
Hartheimer, Howard Cannon, Tom Knight, Jon Taft and Paul Penfield contributed 
help, advice and enthusiasm. 
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2. INTRODUCTORY EXAMPLES 

In this chapter we present three illustrations of the use of DPL. The examples 
are included here to motivate the detailed description of the language in later 
chapters. We suggest the reader look at the examples before reading on, note the 
interesting points, and refer back to the examples while reading the rest of the 
manual. 

The three example cells are described in DPL expressions and are accompanied 
by pictures of their layouts. 

The definition of pass-transistor specifies that an object be built from several 
rectangles called channel, source-diffusion, drain-diffusion and poly-piece. The 
channel region is a rectangle of the layer "channel" whose length and width are 
determined by the parameters passed when this object is built. AH of the parts of the 
pass-transistor are given names. The positions for the source and drain 

diffusions are determined by aligning points on them with points on the channel 
rectangle. Also, a point P is named. An instantiation of the pass-transistor with a 
particular set of values for its parameters is shown in Figure 2A. 

The inverter "calls" the pass-transistor. It also calls a "standard-pullup" which 
is a cell defined elsewhere (see Library). The inverter's parameters are constrained 
so that the inverter-ratio is equal to the ratio of the pullup-ratio to the pulldown-ratio, 
etc. Note that the pass-transistor is placed by lining up its top-center with the 
location of a named point, (DIFFUSION-CONNECTION), the pullup. Also a point, 
(INPUT-PT), the inverter is named (Figure 2B). The location of input-pt is determined 
by following a path of named parts: input-pt is located at the center-left point of the 
part named poly-piece of the part named pulldown of the inverter. 

buffer is a cell that could be used to refresh a signal. It calls inverter twice, with 
different parameters. It thus makes use of two different versions of pass-transistor. 
The version used is determined by how the constraint system sets the values of the 
inverter's parameters when it is called. The second inverter is placed far enough 
away from the first to allow room for the connection. Variables representing 
design-rule constants, *poly-to-poly* and *default-poly-size*, are used to specify 
placement. The connection between the two inverters is made with the DPL wiring 
system. The wire begins at a point on the boundary of a part of a part of a part of 
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input- inverter. It runs horizontally to a point halfway between the inverters and then 
"jogs" to the input of the second inverter (Figure 2C). 

The figures show the structures built when the three object definitions are 
called. They also show how the location of the point named p in pass-transistor is 
transformed as the structures are built. 

Note: The definitions of pass-transistor and inverter presented here are not the 
same as the definitions in the library. They are, however, perfectly legal DPL and 
would "work" as defined. We have made some changes to make the examples 
simpler, buffer is not available in the basic library. 



^ 



(deflayout pass- transistor ;; 

' ((primary -parameters 

((channel-length 2) 
(channel-width 2)))) 
(part 'channel rectangle 
layer 'channel) 
[length (>> channel-length)) 
(width (>> channel -width))) 
(part 'source-diffusion rectangle 
[layer 'diff) 
[length *d if f-overhang*) 
(width {>> channel -width) ) 
[top-center (>> bottom-center channel))) 
(part 'drain-diffusion rectangle 
[layer 'diff) 
[length *di f f-overhang*) 
(width (>> channel-width)) 
(bottom-center (>> top-center channel))) 
(part 'poly-piece rectangle 
[layer 'poly) 

length (>> channel-length)) 
(width (+ (>> channel-width) 

(* *poly-overhang* 2)))) 
(setq-my p (>> center-right poly-piece))) 



PASS-TRANSISTOR 
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(def layout inverter III INVERTER 

^*\ '((primary-parameters 

('(pullup-length 8) 
(pullup-width 2) 
(pulldown-length 2) 
(pulldown-width 2) 
(pullup-ratio nil) 
(pulldown-ratio nil) 
(inverter-ratio nil))) 
(constraints ((c* pullup-length pullup-ratio pullup-width) 

(c* pulldown-length pulldown-ratio pulldown-width) 
(c* pullup-ratio inverter-ratio pulldown-ratio)))) 
(part 'pull-up standard-pullup 

(channel-length (>> pullup-length)) 
(channel-width (>> pullup-width))) 
(part 'pull-down pass-transistor 

(channel-length (>> pulldown-length)) 
(channel-width (>> pulldown-width)) 
(top-center (>> diffusion-connection pull-up))) 
(setq-my input-pt (>> center-left poly-piece pull-down))) 

(def layout buffer ;;; BUFFER 

'((primary-parameters ((input-ratio 8) 

(output-ratio 4)))) 
(part 'input-inverter inverter 
(pullup-ratio 4) 

(inverter-ratio (>> input-ratio))) 
(part 'output-inverter inverter 
(ratio (>> output-ratio)) 

(center-left (pt-to-right (>> center-right input-inverter) 

(+ *poly-to-poly* 

*default-poly-size* 
/""N *poly-to-poly*)))) 

(wire 'connection 

(run-layer 'poly) 

(from (pt-above (>> bottom-right gate-poly transistor pull-up input-inverter) 

(half *default-poly-size*))) 
(to-x (+ (>> x p pull-down input-inverter) 
*poly-to-poly* 

(half *default-poly-size*))) 
(jog~y (>> input-pt output-inverter)))) 
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Figure 2A -- pass-transistor 
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Figure 2B -- Inverter 
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3. THE DATA-BASE 

In this chapter we discuss the data base used by DPL and the vocabulary 
needed to explain the particulars of the language. We discuss the data structures of 
DPL, explain what is in them, and show how they are used by the language to build 
descriptions of designs. 

This chapter need not be understood fully to use the language. The 
implementation details and more complicated ideas are reasonably interesting but the 
only way to understand DPL is to use it. We recommend that this chapter be 
skimmed for the basic ideas and the later chapters examined more carefully - they 
are more useful for using the language. For the most part, the difficulty of a concept 
is inversely proportional to its utility. 

In the sections that follow, various abstract objects are introduced and 
discussed. The low-level implementation of these structures (i.e. lists or arrays or 
whatever) is not important and in most cases is invisible to the user. 



3.1 Types 

A type in DPL holds a procedure that builds data structures. These structures 
contain descriptions of various kinds. The procedure stored in a type is called the 
maker function of the type. A type also contains information about its maker function 
such as the parameters it may take, their default values, and constraints among the 
parameters. A type may also contain information about the structures produced by its 
maker function. 

A type may be thought of as a description of a class of objects that share some 
common features. These objects are the structures produced when the maker 
function is run with various values for its parameters. The structures produced by a 
type thus are related by the way they were created. Usually one creates a type 
whenever a certain object or module is important enough to be given a name. 

In the introductory example, pass-transistor, inverter, and buffer are all types. 
(The command deflayout defines a type.) In all cases we have a certain conceptual 
entity which can nevertheless take a wide variety of forms. Inverters can be built with 
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many ratios, NOR-gates can be built with different numbers of inputs. 

A type may specify that the structure it builds includes structures built by other 
types. Types may thus "call" other types. Objects are built by defining simple types 
which are called by progressively more complicated ones. 



3.2 Prototypes 

The structure that is built by a type is called a prototype. A prototype holds the 
description of certain parts of a design. The prototype and the description in it are 
produced by a "call" to the type with a particular set of values for its parameters. The 
description depends on the values of the parameters in a way that depends on the 
details of the maker function of the type. The different prototypes produced by a type 
will resemble each other since they were produced by the same procedure, but they 
will differ if their parameters differ. 

The distinction between types and prototypes is this: Types hold programs that 

produce prototypes. Prototypes hold descriptions. The user defines types by 

.jT*\ specifying the details of the maker function. The maker function is used to construct 

a prototype and thus a description of a piece of the design. The user never directly 

touches a prototype -- he only tells a type how to build one. 

In addition, the user may place any other information on a prototype he desires. 
It is often useful to name a part of an object or specify the value of a numerical 
parameter. This, as well as the addition of parts to a prototype, is done by inserting 
the appropriate commands in the maker function of the type. 

3.3 Virtual-Copies 

If the maker function of a type "calls" another type, the prototype built by the 
"called" type will be a part of the prototype built by the "calling" type. A prototype 
that is a part of another prototype is called a virtual-copy (VC) in DPL. A VC always 
has two pieces of information on it: its parent, which is the prototype it is a part of, 
and its prototype, which is the prototype being called. 
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available in the VC. The copy is "virtual" because the information is not on the VC, 
but on the prototype of the VC. Thus several prototypes can use a prototype as a part, 
each having a different VC of the that prototype. (See Figure 3.) 

Information about a VC may be obtained by accessing the corresponding part 
or parameter of its prototype. For example, a prototype of inverter will have a value 
for its pulldown ratio. To find the pulldown ratio of a VC of that prototype, an access 
function finds the prototype and gets the information from there. The VC "looks" just 
like its prototype. One may pretend that the prototype's structure is really copied into 
the VC. Prototypes are not copied into VCs because it is more efficient to have only 
one prototype which is pointed to by its VCs. 

It may be necessary to attach other information to a VC besides its parent and 
prototype. A particular VC may have a certain "reason" (for being a simple inverter, 
say, as opposed to a superbuffer). In general, information that is shared by more than 
one VC belongs on a prototype, while information that is specific to a VC may be 
stored there. 

In addition to using some prototypes as parts of others, it is possible to specify 
that a certain type includes "all" of another type, plus some more information. In this 
case, the original type is called the supertype of the one that specifies the changes. 
The subtype has all the parameters of its supertype, plus any others declared when 
the subtype is defined. (See Figure 4.) 

The difference between calling a type as a part of another and declaring a type a 
supertype of another, is that the subtype is really a modified version of its supertype, 
while a part is a different entity from its parent. 

3.4 Instances 

Up to this point have spoken only of information that is "fixed" on objects. 
Parts, parents, and parameters are all kinds of information that must be specified 
when describing an object. It is possible for some information about an object to 
depend on the context in which the object is viewed. An example of this sort of 
information is the geometric transform a VC undergoes when it is actually placed 
somewhere in a design. 
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When building a prototype, it is necessary to specify where each of its parts is to 
be placed. We must specify how the coordinate system of the prototype being used 
as a part is to be transformed in the coordinate system of the parent prototype. In the 
introductory example, the pullup is placed so that its origin is at the origin of the 
inverter's coordinate system (by default). When we use this inverter in another 
prototype we must specify where the inverter is to be placed. The output-inverter of 
the example is placed with its origin at the point (15,0) in the buffer's coordinate 
system. 

The specification of a transformation is not a part of a VC because the same VC 
may be viewed in different ways. The pullup transistor inside the inverter may be 
viewed in the coordinate system of the inverter as the inverter prototype is being built. 
We may then wish to view it later, from a coordinate system in which the inverter is a 
part. 

Another reason that a transform must be separate from a VC is that we want a 
VC to be "the same" (eq) no matter what coordinate system it is viewed from. The 
transform, on the other hand, changes with the viewpoint. 

A VC is contained in an object called an instance which contains a VC and 
"augmentation" describing the context in which the VC is viewed. In the artwork 
description of an object, the augmentation is the transformation of the coordinate 
system of the prototype into the coordinate system of the parent. So in this case: an 
instance is a VC plus a transform. 

Much of this is similar to CIF. Prototypes correspond to CIF symbols and 
instances correspond to calls to symbols. CIF has no need to distinguish between 
VCs and instances because objects are never accessed in CIF except to call them. 

Plato probably had the idea first, speaking of "ideals" of which real world 
objects were just crude imitations. The term "virtual copies" comes from Scott 
Fahlman who used them in much the same way we do. 
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3.5 Storing and Accessing Information 

DPL has functions for storing and accessing information. Some information is 
necessary to specify a prototype's structure, such as its parts. Other kinds of 
information may simplify the design process, such as the named points where wires 
may be attached. A number that is the result of a complicated computation may be 
computed once and stored. For that matter, totally useless information may be stored 
if desired. 

To store information on a prototype, a "cell" is created on the prototype and 
given a name. Any LISP object may then be placed in the cell as its "value". The 
value of an existing cell may be modified by placing a new value into the cell. 

If one of the parts of a prototype is named, a cell on the prototype will be created 
with the part as its value, and the part's name as the name of the cell. This part, an 
instance, may have as its prototype, another prototype with a named part, and so on. 
If one asks for the location of a named point or part "deep" inside several levels of 
parts, the transforms of all the parts must be composed to find the location of the 
object in the current coordinate system. 

DPL provides access functions that are used to extract values from cells. In 
addition to simply extracting values, the access functions will apply the appropriate 
transforms to objects that depend on the context in which they are viewed. In Figure 
2 we show the transforms that must be applied to point P in successive instances of 
the type pass-transistor. 

DPL also provides functions for locating the corner points of an instance as well 
as its bounding box and horizontal and vertical dimensions. 



3.6 What Happens When Something is Made 

When a type is called: 

1 . The values of the supplied parameters are evaluated. 

2. For each parameter defined on the type, a cell is created with that name. At 
this point all the cells have no value assigned to them, but each contains information 
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^m^ about any constraints that apply to it. 

3. The supplied values are then used to fill the cells. If placing a value in a cell 
allows a constraint to run -- because the added value completes one of the sets of 
parameters on which a constraint depends - the procedure for that constraint then 
runs. If the result is to set a previously unassigned cell, then the process repeats until 
no more constraints can run. 

4. When all supplied parameter values have been placed in cells and all 
triggered constraints run, any cells that still have no values are given their default 
values. At this point the system has all the information it will get about how to build 
and place the prototype. 

5. All prototypes built from the same type with the same parameter values will be 
identical. Therefore, before a new prototype is constructed, all previously 
constructed prototypes of the type are examined. If one is found with parameters 
identical to the ones being requested, that prototype is used. Otherwise the maker 
function of the type is run to construct the new prototype. 

f"^ 6. Once the prototype is made or found, a new instance is constructed from the 

prototype. The transform given to the instance depends on whether a transform is 
specified when the type is called. If no transform is specified the instance is given the 
"identity" transform. 

7. The instance may then be named. DPL commands also exist to move it 
around, rotate it, and extract information from it. 
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4. BUILDING THINGS 

In this chapter we introduce the DPL functions which build objects. 

4.1 Creating Types 

The most important aspect of the DPL design process is the creation and calling 
of types. A type is created by a deflayout expression, which contains the maker 
function of the type, a procedural description of the structure created when the type is 
called. 

Deflayout takes the form: 

(DEFLAYOUT <type-name> <param-list> 
<form-l> 
<form-2> 

<form-n>) 
where <type-name> is the name being given to the new type, and <form-i> through 
<f orm-n> constitute the maker function of the type. The forms may include any LISP or 
DPL expressions. <param-i ist> is a list in which each element is a pair of the form 
(<param-name> <vaiue>). <vaiue> may be any LISP object. The only form in this 
expression that is evaluated is <param-i ist>. 

<param-i ist> holds information about the parameters that the maker function of 
the type may take. This information may include parameter names, their default 
values, and constraints among the parameters. <param-iist> may contain all, some, 
or none of the above information. It may also contain other information about the 
type besides that used in the type's maker function. 

To name parameters and assign them default values, a list of the following form 
must be included in <param-i ist>: 

(PRIMARY-PARAMETERS 

((<name-l> <val-l>) 
(<name-2> <val-2>) 

(<name-n> <va!-n>))) 

This list is a pair whose first item is primary- parameters and whose second item is a list 
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of parameter names and values. The <name-i> are the names of the parameters that 
the type's maker function may take. The <vai-i> are the parameters' default values. 

An example of the use of def layout is; 

1 (deflayout square-contact '((primary-parameters ((layer 'poly)))) 

2 (part 'cut rectangle (layer 'cut)) 

3 (part 'cover rectangle (layer 'metal)) 

4 (part 'stuff rectangle (layer (>> layer)) (length 4) (width 4))) 

Here we define a type called square-contact. It has one parameter: layer (the 
material it will be made of) which is given the default value of poly. Lines 2-4 are uses 
of the DPL procedure part which adds a part to the object being built by calling 
another type. Making a square-contact involves creating the parts described in lines 
2-4. 



4.2 The Type RECTANGLE 

The artwork description of an IC design is ultimately decomposable to a 
collection of rectangles. The DPL type rectangle is the primitive type used to build the 
artwork descriptions of other types, rectangle specifies the mask layer and 
dimensions of a rectangular piece of a design. 

The primary- parameters of rectangle are layer, length, and width, length refers 
to the Y dimension of the rectangle, width refers to the rectangle's X dimension. 
Rectangles may only be built with their sides parallel to the X and Y axes, layer refers 
to the materia! from which the rectangle will be made. 

rectangle is defined with the constraint that if either length or width is not 
specified it will be set to the default size for layer. A list of the default layer sizes is 
included in the glossary. 

When using NMOS technology, the available DPL layers are: diff, poly, cut, 
metal, ion and channel. The channel layer is used to represent the channel region of 
transistors. The channel layer is included in DPL to make it possible to explicitly refer 
to the active region of a transistor, as well as to separate the source and drain 
diffusions. In addition, this representation is physically more accurate than simply 
crossing rectangles of poly and diff, since the channel region of an NMOS transistor 
actually contains no diffusion. It is possible, however, to design without using the 
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channel layer. 



4.3 Instantiating Types 

Once a type has been defined with deflayout, instances of that type can be built. 
part is the procedure used to instantiate a type. A call to part creates an instance of a 
type. 

part takes the form: 

(PART <name> <type> (<param-l> <va!-l>) 
(<param-2> <va1-2>) 

(<param-n> <val-n>)) 

where <name> is the name given to the instance which part creates and <type> is the 
name of the type that will be used to create the instance. 

The remainder of the part procedure consists of the parameters that will be 
passed to the maker function of <type>. Parameters and values are passed with a 
"call by keyword" syntax. Each parameter is specified by a pair in which <param-i> is 
/■"N the parameter name and <vai-i> is its value. Any primary- parameters of the type may 

be assigned values. Parameters not listed will take their default values. The 
parameters may be specified in any order. Other information may be placed in the 
parameter list as well (see Section 5.6). 

In the part command, <type> is not evaluated, <name> is evaluated. For each of 
the parameter pairs, <param-i> is not evaluated, <vai-i> is evaluated. 

part is usually used within the deflayout procedure of a type. It is a way of 
specifying the structure that the type being defined will build. When the type is called, 
the instance created by the part command will be included in the structure being built. 

The instance built by a part command is considered to be a "part" of the object 
in which it is placed. It is the parts of an object which constitute the object's structure. 
It is the parts of an object which are displayed when the object is viewed. Tartness" 
is contrasted with other kinds of information stored on an object that do not explicitly 
specify the object's structure. 
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An example of a part procedure is: 

(part 'trans-1 pass-transistor (channel -length 8) (channel -width 4)) 

This creates an instance of pass-transistor. The instance is named trans- i and built 
with a channel length of 8 and a channel width of 4 (lambda). It is shown in Figure 5. 
The type pass-transistor is defined in the introductory example. 
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Another transistor is created by: 

(part 'trans-2 pass-transistor (channel-length 8)) 

This produces an instance of pass-transistor named trans-2 with a channel length of 
8 and a channel width of 2, Since channel-width is not listed in this part procedure, it 
is set to the default value specified for channel-width in the deflayout of 
pass-transistor. See Figure 5. 
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Figure 5 - Two instances of the type PASS-TRANSISTOR 
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4.4 The Structure Built by a Type 

When a type is called with part, the LISP variable *me* (pronounced 
M star-me-star H ) is bound to the representation of the structure being built by the 
type's maker function. In other words, while a structure is built, it is attached to *me*. 
This means that when a type is called, *me* will be bound temporarily to the type's 
parts as they are built. When the maker function of the type is finished, the structure 
in *me* is placed in an instance. This instance may very well be a part of another 
structure. 

Since a deflayout is a specification of a type, when writing a deflayout, one can 
think of the structure that will be built when the type is called as *me*. *me* acts as the 
temporary name of the structure while it is being built, so that it is possible for 
information to be added to and retrieved from the structure. We have already seen 
one way in which information is added to the structure built by a type - the part 
command makes the instance it produces a "part" of *me*. 



4.5 Naming Things 

In the course of the design process, it is often useful to store information on 
*me*. Such information may be useful for constructing *me* or it may be useful later, 
when the instance is complete, for building other objects. 

The function set-my stores a piece of information on *me* and gives it a name. 

(SET-MY <name> <value>) 

stores <vaiue> on *me* and names it <name>. <vaiue> may be any LISP object, set-my 
evaluates both its arguments. The function setq-my is identical to set-my except that 
setq-my does not evaluate <name>. Thus setq-my is often more convenient to use, and 
we will use it in most examples. 

The values stored by setq-my may be accessed by the DPL access functions 
described below. 

For example, within the deflayout of a type, the locations of several parts may 
depend on the height of the VDD bus. ( setq-my vdd-height 20 ) will store the value 20 
on *me* and will name it vdd-height. It is possible to access this value later in the 
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deflayout to specify the locations or dimensions of parts of *me*. 

4.6 Accessing Parts and Parameters 

Within a deflayout procedure it is often necessary to refer to parts of *me* (or 
parts or parameters of those parts), as well as to information placed on *me* by 
setq-my. Accessing such information can be done with the function >> (called 
"arrow-arrow"). 

(>> <thing-l> <thing-2> . . . <thing-n>) 

will retrieve the value of <thing-i> which belongs to <thing-2>. . . which belongs to 
<thing-n> which belongs to *me*. (None of the elements in an >> form are evaluated 
unless they are non-atomic.) 

For example, suppose we are writing the deflayout procedure for a type named 
register which includes as a part an instance named shift-cell, shift-cell, in turn, 
contains as a part an instance of pass-transistor named trans-3. To find the value of 
the channel-length of trans-3 of shift-cell of register, we write: 

(>> CHANNEL-LENGTH TRANS-3 SHIFT-CELL). 

(This expression is read: "The channel-length of trans-3 of shift-cell of *me*.") 

To access a part or parameter of *me*, or a something stored on *me* by setq-my, 
we write: 

(>> <thing>) 

For example, (setq-my vdd-height 20) followed by (>> vdd-height) will return 20. 

>> is used to access the values of the parameters with which the type was 
called. This is the way in which the parameters direct the construction of an instance. 
The deflayout of pass-transistor has two parameters, channel-width and 
channel-length, (see Introductory Examples). The following command is included in 
the deflayout of pass-transistor: 

(part ? diff-piece rectangle 
(layer 'diff) 

(length (+ (>> channel -length) (* 2 *diff-overhang*)) ) 
(width (>> channel-width))) 

This command specifies the values for the parameters length and width of the type 
rectangle by accessing the values that channel-length and channel-width are assigned 
when pass-transistor is called. If we call pass-transistor in the following way: 
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(part 'trans-4 pass- transistor 
^*\ (channel-length 4) 

(channel-width 100)) 



j^ m S 



channel-length and channel-width are assigned to the values 4 and 100. These values 
are then used when the type rectangle is called by the maker function of 

PASS-TRANSISTOR. 



4.7 The General Access Function 

The general DPL access function is the. 

(THE <name> <thing>) 

finds the information named <name> on <thing>. (Both arguments are evaluated.) the 
knows about all DPL structures and may be used to access parts and parameters of all 
of them. For example, one may use the following to find the primary-parameters of a 
type named a-type: 

(the 'primary-parameters 'a-type) 

the may also be used to access named information from *me*. For example, the 
following two expressions will return the same value: 

(the 'channel-length *me*) 
(>> channel-length) 

In fact, >> is defined in terms of the. The expression 

(>> mumble fumble grumble) 

expands to: 

(the 'mumble (the 'fumble (the 'grumble *me*))) 

>> is the most useful way to get information from *me* and is usually used in 
deelayout expressions, the is used to get information from objects other than *me* and 
thus is most useful when interacting with LISP while debugging designs. 

When accessing information from parts of objects the and >> transform the 
objects correctly so that the object is always viewed in the current coordinate system. 
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4.8 Additional Features of DEFLAYOUT 

There exist additional capabilities of deflayout which are not used as often as 
those described above. This section will introduce these capabilities. 



4.8.1 Supertypes 

deflayout allows one to make new types by adding to old ones. <type-name> may 
be written as a list of two elements, the first name referring to the name of the new 
type, the second name referring to the name of the old type. A new type is made 
which is identical to the old type, but with the addition of whatever information is 
included in the new deflayout procedure. The previously defined type is called a 
supertype of the new one. The new type has all the parts and parameters of the 
supertype, yet it may be given additional parameters as well as additional parts. 

An example of the use of a supertype is a depletion-mode transistor. It is 
identical to a normal transistor with the addition of a rectangle of ion implantation. 
The definition of a depletion-mode transistor is: 

j****\ (deflayout (rect-d-fet rect-fet) '() 

(part 'implant rectangle 
(layer 'ion) 

(length (+ (>> channel -length) (* 2 *ion-overhang*) )) 
(width (+ (>> channel-width) (* 1 *ion-overhang*) ) ) 
(center (>> center channel)))) 

In this example, rect-d-fet is the name of the new type, rect-fet is the name of the 
type that constructs "normal" transistors -- it will be the supertype of rect-d-fet. 
rect-d-fet includes all the parts and parameters of rect-fet with the addition of the 
part created in the example above, a rectangle of ion implant. Note that our new type, 
rect-d-fet, includes no parameters in its parameter list. However it actually does 
have parameters - the parameters of rect-fet (which happen to be a channel-length 
of 2 and a channel-width of 2). rect-d-fet could have been given additional 
parameters, but here we have limited its parameters to those of rect-fet. 

A supertype is used if a type being defined differs only slightly from a 
pre-existing type, and it is desired that the new type have the same or very similar 
parts and parameters as the supertype. The advantage to using the supertype 
construction rather than calling the supertype as a part is that only the differences 
between the new type and the supertype need be specified. 
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4.8.2 Additional Parameters to DEFLAYOUT 

The values of a type's primary parameters determine the structure of its 
instances, deflayout may also be given parameters which specify information about 
the type other than that which directly determines the structure of its instances. 

The auxiliary-parameters of a type is a list of some of the names used to store 
information on the instances of the type. For example, if a point named comnection-pt 
is named with a setq-my command inside a deflayout, the name connection-pt may be 
included in the auxiliary-parameters of the type. Auxiliary- parameters are usually 
used by programs which manipulate types, such as the constraint system described in 
Chapter 7. Auxiliary- parameters are included in a type by placing a list of the 
following form in the <param-i ist> of a deflayout: 

(AUXILIARY-PARAMETERS (<namel> <name2> . . .)) 

where the <namei> are names that will be assigned to things in the body of the 

DEFLAYOUT. 

Other information may be specified in a deflayout parameter-list. Any pair of the 
form: 

(<name> <va1ue>) 
in the <param-iist> of a deflayout will cause the information in <vaiue> to be stored on 
the type and named. Documentation, version numbers, device parameters are all 
kinds of information one might want to store on a type. 
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5. PLACING THINGS 

When defining a type it is necessary to specify both the structure of its parts and 
their location. This chapter will explain the DPL functions, data structures, and 
variables used to specify placement. 

5.1 Coordinate system 

Every structure specified by a deflayout has its own coordinate system. Each 
part procedure in the deflayout will place the instance it creates at a certain position 
in the coordinate system of *me*. Unless the part command is given explicit 
placement information, the part is placed with its origin at the origin of *me*. 

Since parts are themselves calls to types, each part is constructed with its own 
coordinate system in which its parts are placed. However, within a deflayout 
procedure all parts of parts are transformed when accessed by the or >> to their 
positions in the coordinate system of *me*. 

5.2 Points 

Points may be created by the function pt. 

(PT <x-coord> <y-coord>) 

creates a point with the given coordinates in *me*. For example, (pt 4 3) creates a 
point with the coordinates (4,3). pt is often used with the DPL placement functions 
which will be explained in this chapter. 

The X and Y coordinates of a point may be accessed by the functions >> or the. 
If the expression 

(setq-my connection-point (PT 5 6)) 

is used in a deflayout, the function 

(>> x connection-point) 
will return 5. 

DPL provides a number of functions which deal with points. They include 
functions which construct new points from existing ones, a function which tests 
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jm^ values for "pointness", and functions dealing with the placement of points. These are 

explained in the glossary. 



5.3 Implicit Parameters 

Every instance possesses pre-named information useful for placing the instance. 
This information is called an instance's implicit parameters because it is never 
explicitly placed on the object, yet it may be accessed. 

Probably the most useful of the implicit parameters are corner-parameters 
and apparent-corner-parameters, pre-named points on every object which 
contain the locations of an object's corners, center-side-points, and center. The 
corner- parameters are: 

top-left top-center top-right 
center-left center center-right 
bottom-left bottom-center bottom-right 

The corner-parameters refer to the locations held by the appropriate points in 
the coordinate system of the object before the object had been transformed. If the 
instance has been rotated or mirrored the corner- parameters will be transformed as 
well. Thus, for example, the top-center of an instance that has been rotated 90 
degrees counterclockwise will be on the left side of the instance. 



r\ 



/"*\ 



It is often more useful to refer to the points on an instance which indeed appear 
to be the top-right, bottom-center, and so on. The apparent-corner-parameters are 
provided for this purpose. The names of the apparent-corner-parameters are 
obtained by concatenating "apparent-" with the names of the corner- parameters. 

Figure 6 shows how the corner- parameters and apparent-corner-parameters of 
an instance transform when the instance is transformed. 

The values of corner-parameters and apparent-corner-parameters may be 
accessed by >>. For example, 

(>> apparent-bottom-right gate-poly pulldown inverter-1) 

will access the apparent-bottom-right of the gate-poly of the pulldown of inverter-i of 

*ME*. 

Corner-parameters and apparent-corner-parameters are useful for the 
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placement of objects. They allow objects to be placed by reference to other objects, 
rather than by their numerical coordinates. Corner parameters contribute to the 
flexibility of the design because relative placement allows one to change or move a 
part without changing the specification of the objects near it. Corner parameters are 
also useful in that they reveal the reason for the particular positioning of a part, far 
more than a numerical parameter. 

Other implicit parameters of every instance are boQnding-box, origin, xdim, and 
ydim, The bouwding-box of an instance consists of a representation of two diagonally 
opposite points on an imaginary rectangle surrounding the instance. It is computed 
by taking the extreme values of the coordinates of the bounding-box of the parts of 
the instance, or the corner points if the instance is a rectangle. 

The origin of an instance is the point (0,0) in the coordinate system of the 
instance. Accessing the origin of a part of *me* or of a part of a part will give the point 
in the coordinate system of *me* that the origin of the part occupies. 
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^m^ The xdim of an instance is the distance between the center-left and 

center-right of the instance. The apparent-xdim is the distance between the 
apparent-center-left and apparent-center-right of the instance, ydim and 
apparent-ydim give the corresponding distances between the top-center and 
bottom-center. 

5.4 Translation 

One way to place parts within a deflayout procedure is to make the part with a 
part procedure, and then move the part to the desired location. When a part is 
created it is placed at the origin of *me*. It may then be translated to the desired 
location by the DPL function align. 

align moves an object to another location, maintaining its orientation (without 
rotating or mirroring it). 

align takes the form: 

(ALIGN <object> <ref-point> <target-point>) 

/0\ where <object> is the thing to be moved, <ref-point> is a point, usually on the object, 

and <target-point> is the point to which <ref-point> is to be relocated. <object> will 
be moved so that <ref -point) is at <target-point>. All three arguments to align are 
evaluated. 

For example, 

(al ign (>> contact-1) 

(>> top-center contact-1) 

{>> bottom-center source-diffusion trans-1)) 

will move contact- 1 so that its top-center is at the bottom-center of the 
source-diffusion of trans- 1. This example is illustrated in Figure 7. 

5.5 Unitary Transforms 

Instances may be rotated or mirrored by the unitary transform functions. Each 
unitary transform function corresponds to an element of the group of symmetries of 
the square. Each unitary transform function takes an instance as an argument and 
transforms the instance as described below. Rotation and mirroring is performed 
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about and across the origin of *me*. 

identity Performs no rotation or mirroring of the instance. 

R0T90 Rotates the instance 90° counterclockwise. 

ROT180 Rotates the instance 180°. 

ROT270 Rotates the instance 270° counterclockwise. 

negx Negates the X coordinates of the instance. (Mirrors the instance 

across the Y axis.) 

negy Negates the Y coordinates of the instance. (Mirrors the instance 

across the X axis.) 

int-pos The composition of ROT90 followed by negx. (The values of the 
coordinates are interchanged.) 

int-neg The composition of ROT90 followed by negy. (The values of the 
coordinates are interchanged and negated.) 



For example, 

(negx (>> trans-7)) 
will mirror the instance named trans-7 across the Y axis. 



/O 



Note that each application of a unitary transform function to an instance 
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^*\ composes the new transform with the previous transform of the instance. 

If both align and unitary transform functions are to be applied to an instance, it 
is usually more convenient to apply the unitary transform functions before translating. 
This is because translation is usually used to place the object in its final location. If 
one translates before rotating or mirroring, it is very difficult to predict where the 
instance will be ejected. 



5.6 Placement by Parameter 

We have seen that objects may be created and then moved around. It is also 
possible to place objects by supplying parameters to the part procedure. 

The translation of an object may be specified by including as a parameter to part 
the name of a reference point on the object and its target location. The points most 
commonly used as translation parameters are corner- parameters and 
apparent-corner-parameters. For example, 

(part 'contact-1 square-contact 
(layer 'diff) 
f^ (top-center (>> bottom-center source-diffusion trans-1))) 

will do the same thing as 

(part 'contact-1 square-contact (layer 'diff)) 

(align (>> contact-1) 

(>> top-center contact-1) 

(>> bottom-center source-diffusion trans-1)) 

Note that when passing the name of a point to part, as a reference point on the 
object, >> is not necessary. (Like the point top-center in the example above.) 

Points other than corner-parameters and apparent-corner-parameters may also 
be used as reference points. For example, if connection-point was a named point on 
an inverter, 

(part 'inverter-1 inverter 

(connection-point (>> bottom-left poly-rect))) 

would place inverter-i so that connection-point was at the bottom-left of poly-rect. 

Rotation and mirroring can also be performed by supplying parameters to part, 
part may be called with a parameter whose name is xfrm and whose value is the name 
of one of the unitary transform functions, in which case the unitary transform function 
.p.. is applied to the instance. 
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^m^ If both a translation parameter and a unitary transform are passed as parameters 

to a part procedure, they may be listed in any order. The unitary transform will be 
applied to the part before it is translated. 
For example, 

(part 'be butting-contact 
(xfrm ' rot90) 
(bottom-center (>> center-left gate-poly trans-1))) 

will rotate butting contact bc 90°, and then place it so its bottom-center is at the 

CENTER-LEFT of the GATE- POLY of TRANS-1 of *ME*. 

The two methods of placing objects - placement by function and placement by 
parameter -- each have advantages in certain situations. Placement by parameter is 
less wordy than placement by function. However placement by function is often 
easier to read, especially when either the reference point or the target point is a 
complex formulation, or when one is passing many parameters to the part procedure. 

For example, 

(part ' iv2 inline-inverter 
(enhancement-width 10) 
(enhancement-length 3)) 
(int-neg (>> iv2)) 
(align (>> iv2) 
*0*>\ (>> apparent-top-right iv2) 

■ (pt (- (>> x top-left poly-contact) 2) 

{- (>> y bottom-right VDD-contactl ) 3))) 

is equivalent to 

(part ' iv2 inline-inverter 
(enhancement-width 10) 
(enhancement-length 3) 
(xfrm ' int-neg) 
(apparent-top-right (pt (- (>> x top-left poly-contact) 2) 

(- (>> y bottom-right VDD-contact) 3)))) 



5.7 Invoke 

Many of the objects created during the course of a design are meant to "line up" 
or "fit" other objects. The driver for a PLA column, for example, must be the same 
width as the column, and its outputs must match up with the inputs of the column. 
The design of such types is made easier if an instance of the other object is available 
to match up with the one being made. 

The DPL function invoke is identical to the part function but the instance that is 
^^ created is not made a "part" of the new object. The invoked instance may be moved 
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around and the information inside it may be accessed, but the structure of the new 
type will not include the structure of the invoked type. 

Example: 

(deflayout pla-driver () 

(invoke 'column pla-column-cel 1 ) 

(part 'vdd-bus rectangle 
(layer Vnetal ) 

(center-left (>> center-left column)) 
(center-right (>> center-right column))) 

<and more forms of the maker function>) 

This shows how a type is invoked and then used to specify the dimensions of 
another cell. Note that the pla-column-cell will not be a part of the pla-driver, but the 
information in the column cell can be used as the driver is being built. 

5.8 *L!ST* 

Many DPL objects keep lists of other kinds of objects. Some of the lists contain 
objects that are "transformable", like instances or points. In this case it is useful to 
have them transformed into the current coordinate system. The DPL structure that 
allows this to be done is called a *list*. If a *list* is stored in a cell on an object, 
each element of the *list* will be transformed as it is "brought out" of the structure 
with the or ». 

A *list* is made out of a LISP list by the function make-list-of, the list inside a 

*list* is obtained with the function the-list-of. For example: 

(deflayout a-usel ess-type () 

(part 'moe rectangle (layer 'poly)) 
(part 'larry rectangle (layer 'diff)) 
(part 'curley rectangle (layer 'metal)) 
(setq-my stooges (make-list-of 

(list (>> moe) 

(>> larry) 

(» curley))))) 

creates three rectangles of default sizes on top of one another and a *list* 
containing them is made. If the following code is in the maker function of another 
type: 

(part 'meanies a-useless-type (bottom-left (pt 100 100))) 

asking for (the-iist-of (>> stooges meanies)) gives the list of the three instances, 
each transformed correctly. 
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6. THE DPL WIRING SYSTEM 

Most of the rectangles in a large design serve to connect objects. This chapter 
introduces the DPL wiring system which consists of special procedures for creating 
and manipulating such rectangles. 

Wires are specified by indicating the layer and width to be used, and the path 
the wire is to follow. Wires may change layers, in which case the wiring system will 
automatically insert the correct contact, or make any number of side branches. 

Wires are made by placing rectangles. In the DPL wiring system, wires are 
placed by aligning new rectangles of a specified width and layer so that they join 
previously placed rectangles. The length of each rectangle is determined by the path 
the wire is to follow. 

To join rectangles, wires make use of a special kind of point called a 
connection-point (CP). A CP is a data structure which keeps track of the layers of 
the wires connecting to it as well as its coordinates. The current-CP of a wire is a CP 
containing the point where the next rectangle is to be attached. The current-CP may 
be thought of as the current position of the wire. 

Wires are considered to be parts of *me*. During the construction of a wire, the 
variable *the-wire* will be bound to the wire being constructed. Wires are instances 
of the special type wire. Like all instances, they have implicit parameters which may 
be useful when placing other parts of *me* near wires. The bounding-box of a wire is 
computed by finding the extreme values of the coordinates of its component 
rectangles. 



6.1 Wire System Commands 

The most common way to use the wiring system is with the procedure wire, wire 
is usually used within a deflayout and takes the following form: 
(WIRE <name> . . <1 ist-of-wire-commands>. . ) 

wire names the wire it builds <name>. <name> is evaluated. If <name> is nil the wire is 
given no name. The first and last CP's of the wire are named start and end. The 
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construction of the wire is controlled by the following commands which may occur 
inside a wire procedure. (Each wire command evaluates its argument.) 

(run-layer <iayer>) sets the layer of the wire. If the wire had already placed 
rectangles of a previous layer, the next time a rectangle is placed the appropriate 
contact is made at the wire's current-CP. The run-layer command sets the width of 
the wire to the default width for that layer (see Glossary). A run-layer command must 
come before any of the commands that actually place rectangles. 

(run-width <width>) sets the width of the wire, run-width must come after the 
run-layer command if it is to affect the width of that layer. 

(from <piace>) sets the current-CP to <piace>. <piace> may be a point, a CP or 
another wire. If <piace> is a wire, the last CP of the wire is used. A from command 
must precede any of the commands which actually place rectangles. The from 
command may be used at other places inside a wire command in which case it moves 
the current-CP from its previous location to <piace> without placing any rectangles. 



(T0-X<place>) 
f*^ (T0-Y<p1ace>) 



These commands place rectangles. <piace> may be a number, in which case it is 
interpreted as a coordinate of the destination of the wire in the specified direction. If 
<pi ace> is a point or a CP, the appropriate coordinate will be extracted and used. Like 
all commands that place rectangles, this may cause a contact to be dropped if the 
layer has been changed since the last rectangle was placed. The current-CP is then 
updated to the new point. 

(to-pt <piace>) places a rectangle which extends from the current-CP to 
<piace>. <piace> may be either a point or a connection-point. One of its coordinates 
must be equal to a coordinate of the current-CP. 

(+X <number>) 
(+Y<number>) 
(-X<number>) 
(-Y<number>) 

Each of these commands extends a rectangle from the current-CP the specified 
distance in the specified direction. 
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^ (JOG-X<place>) 

(J06-Y<p1ace>) 

These commands extend the wire to the point or CP specified by <piace> by 
running first in the specified direction and then in the other. For example, if the 
current-CP is at point (0,0) and the command (jog-y (pt 10 io)) is given, the result is a 
rectangle from point (0, 0) to point (0, 10), and then a rectangle from point (0, 10) to 
point (10, 10). 

(Save-cp <name>) names the current-CP of the wire <name>, and stores it so it may 
be accessed later. 

(RESTORE-cp <name>) moves the current-CP of the wire to the specified 
connection-point. 

(drop-contact) places a square contact of the current layer at the current point. 

In addition, any LISP or DPL forms may be placed in a wire form. It is often 
useful to use LISP conditionals to direct the construction of a wire. Any DPL 
commands that create or name structure (such as part and setq-my), except the above 
^-N wiring commands, will affect the object the wire is part of, not the wire itself. 

6.2 Wire System Example 

The following is an example of the use of the DPL wire system. In the example 

we assume that *me* has been given the parts trans- i and irans-2 which are 

pass-transistors, and cont-i which is a poly-to-metal contact. The example is 

illustrated in Figure 8. 

(wire 'wire-ex 

(run-layer 'diff) 

(from (>> bottom-center source-diffusion trans-1)) 

(-y 4) 

(to-x (>> center cont-1)) 

(save-cp 'fork) 

(j°9" x (>> bottom-center source-diffusion trans-2)) 

(restore-cp 'fork) 

(run-layer 'poly) 

(to-y (>> top-center cont-1))) 

Our wire, wire-ex, begins as a wire of diffusion at the bottom-center of the 
source diffusion of trans- i. After running 4 lambda down, it runs to the X coordinate 
of the contact comt-i. The current-CP is then saved and named fork because we will 
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Figure 8 -- Wire System Example 
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/~\ want to resume wiring from there later. The wire is then run with a jog-x command to 

the bottom-center of the source diffusion of trans-2. The saved CP fork is then 
restored, and the layer is changed to poly. Finally, we run the wire from the restored 
CP to the top of cont-1. Note that the wiring system automatically places a butting 
contact where the layer changes. 

6.3 External Wire Commands 

Wires may be given additional rectangles after they have been made. The 
commands which do this correspond to the above commands except that the names 
have "wire-" concatenated to the front. Each external wiring command takes two 
arguments: the first is the wire to be manipulated, the second is the same argument as 
that passed to the corresponding internal wiring command. For example: 
(WIRE-JOG-X <wire> <p1ace>) 

It is possible to build a wire entirely from the "outside". An empty wire may be 
created by using wire with a name and no other wire commands. The wire can then 
be given rectangles with the external wiring commands. 



r\ 



/""N 



6.4 Connection Points 

CPs named during the construction of a wire may be accessed during the 
construction of the wire. The special symbol *current-wire*, when used as the last 
symbol in an >> command, allows one to access a named CP of the current wire. For 
example: 

(>> fork *current~wire*) 

After a wire is complete, a named CP may be accessed as if it were named information 
on the wire. In the wire system example above, 

(>> fork wire-ex) 

will access the CP fork. 

The point which is the location of a CP is obtained with the function pt-cp. For 
example, 

(pt-to-left (pt-cp (>> fork wire-ex)) 5) 

will return the point which is 5 to the left of the fork of wire-ex. 
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One may access the X and Y coordinates of a CP as if it were a point: 

(>> x fork wire-ex) 

It should be noted that when the wiring system automatically places a butting 
contact at a CP, the butting-contact is placed with its center at the CP. This means 
that other poly or diffusion wires connecting to the butting contact may not end 
directly at the CP, but at a point to one side of it. In the example in figure 8, if we were 
to attempt to run a horizontal poly wire from the CP named fork, the poly actually must 
connect 1 lambda below the CP -- or else it would partially cover some diffusion and 
make an illegal butting contact. The wiring system automatically adjusts the 
endpoints of the wires to make legal butting contacts, but in so doing may cause the 
wires to begin and end on points other than the specified CP. One should use the jog 
commands near butting contacts to allow the system to bend wires when such 
situations develop. 
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^ 7. CONSTRAINTS 

In many cases the parameters of a type are related. Often some parameters may 
be derived from others. The DPL language uses constraints to allow the user to 
specify only those parameters necessary to "constrain" the rest. 

For example, a standard transistor's resistance is determined by the ratio of its 
channel length to its channel width. If the ratio is z, the channel length l, and the 
channel width w, then z = l/w. But also zw = l and w = l/z. The complete 
specification of the transistor may be accomplished by setting only two of the three 
parameters. 

Constraints do more than allow one to specify fewer parameters. Much of the 
computation necessary for determining the layout of an object can be done with 
constraints. For example, it may be necessary to fix a transistor's ratio and width, 
allowing its length to vary. In another case one may want to specify the length and the 
width of a transistor and later ask for its ratio. Or, one could specify all three and let 
the program complain if they were set inconsistently. 

^"^ In some cases it is useful to specify constraints among parameters which are not 

used to build the instance. For example, the width of a cell may be determined by the 
distance between two control lines. We may write a constraint between the positions 
of the control lines and the width of the cell. If the points where the control lines enter 
the cell are named as auxiliary parameters of the type, it is possible to express the 
width of the cell in terms of these positions. 



7.1 Using Constraints 

To specify constraints between parameters of a type, the following list must be 
included in the <param-i ist> of the type's deflayout: 

(CONSTRAINTS ((<c-l> <param-l> <param-2>) 

(<c-2> <param-3> <param-2> <param-4>))) 

The <c-i> are names of constraints. Several constraints have already been defined 
(see library); others may be defined by the user. The <param-i> are the names of 
primary or auxiliary parameters of the type among which the constraint is to be 
applied. A single parameter may be mentioned in several constraints. 
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f*\ A useful constraint is c* which constrains three arguments so that the first is the 

product of the second and third, c* may be used to specify the constraints of a 
transistor: 

(deflayout ' transistor-1 transistor 

'((primary-parameters ((channel-width 2) 

(channel-length 2) 
(ratio 1))) 
(constraints ((c* channel-length ratio channel-width)))) 
...forms of the maker function...) 

This example uses only one constraint and applies it to three primary- parameters. 

If it is desired that one of the arguments be a constant, that value (usually a 
number or a point) may be given to the constraint directly, instead of passing the 
name of a parameter. For example, one may wish to maintain a ratio of 4 between an 
inverter's pullup-ratio and its pulldown ratio. This could be accomplished by: 
(c* pullup-ratio 4 pulldown-ratio) 

If an attempt is made to specify an inconsistent set of parameter values to a type 
defined with constraints, an error will be signaled. 



/""N 7.2 Defining Constraints 

Constraints are defined by the command defconstraint. A constraint must be 
defined before it can be used in a deflayout. 

defconstraint takes the form: 

(DEFCONSTRAINT <name> <arglist> 

(<arg-l> (<arg-2> <arg-3>) <procedure>) 
(<arg-2> (<arg-l> <arg-3>) <procedure>) ) 

where <name> is the name used to call the constraint. <argi ist> is a list of the variables 
that will be bound to the values specified when the constraint is called. The forms 
following <argi ist> each begin with the name of one of the variables. This is followed 
by a list of the variables that can be used to compute the first variable if they all have 
been given values. The last item is the actual procedure that can be run, using those 
variables, to compute the value of the first variable. The best way to clarify 
defconstraint is to present the definition of a simple constraint: 
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(defconstraint c* (prod ml m2) 
(prod (ml m2) (* ml m2)) 
(ml (prod m2) 
(if (= m2 0) 
'bail-out 

(// (float prod) m2))) 
(m2 (prod ml) 
(if (= ml 0) 
'bail-out 
(// (float prod) ml)))) 

This is the c* constraint discussed above. It takes three arguments, and 
constrains the first to be the product of the other two. If the procedure evaluates to 
the string bail-out, the constraint will not attempt to set a value. 

Constraints may be used between primary-parameters, auxiliary-parameters and 
constants. It is also possible to specify corner and apparent-corner parameters as 
arguments to a constraint. In fact, the type rectangle is defined this way. One may 
specify the bottom-left and upper-right of a rectangle, for example, and the constraint 
will determine the proper length and width to make the rectangle. 
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S^ 8. REPLICATORS 
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Many designs contain situations in which a small number of objects are 
replicated in highly regular arrangements. A row of identical register cells may be 
used to store the result from a column of bit-slice adders. A PLA or a shifter is 
typically made of a two-dimensional grid of identical parts. 

Replicators in DPL allow the user to create such structures. They also make 
use of the regular nature of the structures to represent them efficiently. All that is 
stored is the list of instances which appear in the replicator and a function that 
computes the transform of an instance for a given set of coordinates. The functions 
examining the structure of the replication put this information together and produce 
the parts of the replication. When examined with the, a replication "looks like" it has 
many parts, while actually only a few instances are stored. 

The most useful replicators build rows, columns or 2-dimensional grids of 
instances. These replicators are defined in the library. It is also possible to define 
replicators for special purposes. 

A "replicator" is similar to a type. It holds the procedure to construct a 
replicated set of instances. A "replication" is what a replicator produces » an 
instance that looks like it has many regularly placed parts. 

8.1 Calling Replicators 

If a replicator has been defined, it is called with the command replicate: 

(REPLICATE <name> <rep I icator-type> <dimensions> <"! ist-of- instances) 

. . . <other-parameters>, . . ) 

This command is similar to the part command except for the <dimensions> and 
<i ist-of -instances) arguments, which are both evaluated. It calls the replicator 
named <replicator-type> and gives it the name <name> in *ME*. The <dimensions> 

argument is a list of the values of the dimensions the desired replicator. The 
<iist-of-instances> is a list of instances that will be used in the replication. These 
instances may have been invoked or actually made as parts of *me*. In either case, 
after the replicate command, they will be removed from wherever they were before 
and treated as parts of the replication. 
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The replicator row takes a single instance and places a row, spacing the parts 
using the sum of the parameters pitch and spacing. If the parameter pitch is not 
specified in the call to replicate, the instance is checked to see if it has an h-pitch 
parameter. If so, that value is used. Otherwise, the apparent-xdim is used. (Needless 
to say, this is done with constraints.) The spacing parameter defaults to zero. The 
following commands 

(invoke 'pi rectangle (layer f poly) (length 10) (width 10)) 
(replicate ' rl row (10) (list (>> pi)) 
(spacing 1)) 

give a replication of ten poly squares, spaced one apart. 



8.2 Accessing Replications 

The parts of a replication may be accessed by the form 

(*REP <coord-l> <coord-2>) 
within a call to the or >>, where the <coord-i> are the coordinates desired. The 
arguments are evaluated. The coordinates start with (o o). If the replication is 
one-dimensional, the second coordinate may be unspecified, or else must be 0. Thus 

f\ (>> (*rep 3) rl) 

gives the fourth element in the row produced above. The symbol *rep-first is used to 
access the <o 0) element in a replication, and *rep-last accesses the element in the 
replication with the largest coordinates. These are useful when the size of a 
replication is a parameter and one wants to refer to the end or beginning of it. For the 
above replication then, the following forms are equivalent: 



and 



(>> *rep-first rl) 
(>> (*rep 0) rl) 



(>> *rep-last rl) 
(>> (*rep 9) rl) 



Besides their parameters, replications contain additional information. The 
instance-list of a replication contains the list of instances used when the replicate 
command was called. The form (*rep-instance <n>) is used to get the nth element of 
the instance-list of a replication. The cell max-dims of a replicator contains a list of 
the maximum-dimensions of the replication, max-dims is the same as the argument 

<dimensions> to REPLICATE. 
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/^*s 8.3 Defining Replicators 



Replicators are a special kind of type. They may be defined with constraints and 
parameters. A replicator is defined as follows: 

(DEFREPLICATOR <name> (coordinates) 
<param-list> 
(body)) 

The <name> and <param-iist> are as in deflayout: <name> will be the name of the 
replicator and <param-i ist> its parameter-list. The <coordi nates) argument is a list of 
one or two symbols. The length of (coordinates) will be the dimension of the 
replication. <body> is a collection of LISP forms that are called when the replication is 
accessed. The functions in <body> determine the instance and transform of the "part" 
of the replication determined by the coordinates. As in deflayout, only < P aram-i ist> is 
evaluated. 

The call (*rep <i> <j>) binds the variables in the (coordinates) list to <i> and <j>, 
and binds *me* to the replication. Then <body> is evaluated. 



j*-^ <body> must call the functions: 



(REPLICATOR- INSTANCE (instance)) 
(REPLICATOR-TRANSFORM (unitary-part) (x> (y>) 

The argument to replicator- instance is the instance at the position specified by 
the value of the coordinates. It is obtained by a call to *rep-instance and is 
determined by the values of the coordinates and perhaps some of the parameters. 

replicator-transform takes as arguments the three parts of the transform to be 
composed with the transform of the argument to replicator- instance. This yields the 
transform of the part of the replication, the and >> use the arguments to these 
functions to construct and return the correct instance. 

The following is the definition of the row replicator: 
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(def repl icator row (i) 

'((primary-parameters 
(pitch 

(spacing 0))) 
(constraints 

(h-pitch instance-list pitch))) 
(replicator-instance (>> (*rep-instance 0))) 
(replicator-transform 'identity 

(* i (+ (>> pitch) (>> spacing))) 
0)) 

The h-pitch constraint acts on the instance-list of a replication to find the 
horizontal-pitch as described above, row takes only one instance and all its parts have 
the same unitary-transform and Y position. The X position is determined by the 
product of the coordinate and the sum of the parameters pitch and spacing. Thus for 
the row replication created above, the call (>> (*rep 4) ri) returns an instance of a 10 
by 10 poly rectangle with a transform of 44 in the X direction. 
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f^s 9. USING DPL 



In this chapter we discuss how the DPL language can be used to construct a 
project. We explain what the various kinds of DPL objects look like when they are 
displayed on a terminal and how the designer may use DPL at a terminal to probe the 
structure of his design. We also discuss the functions that translate between DPL and 
CIF. 



9.1 Interacting with DPL 

When the DPL system is loaded into a LISP environment, a special object is 
created. This object, called a top, is very similar to a prototype. *me* is bound to a top 
so that commands which would otherwise appear in the maker function of a type may 
be executed at top-level LISP, the results affecting the top. 

For example, typing 

(part Mvl inverter) 

at top-level will make an inverter and name it ivi in *me* - which is bound to the top. 
One may then say 

(>> ivl) 

and get the instance of the inverter. Tops are represented by the string "layout" 
followed by a number: layout- 1. In most cases this is the only top that will be seen. 

Calling types interactively (by calling part at top-level) is the way to debug 
designs. One defines types while working with a text-editor and then loads the text 
files into a DPL environment where he may then examine the structures of the types. 
On some systems where DPL may be used, graphics programs can display pictures of 
instances. Just running the maker function of a type, by using part, is a good way to 
see if the code is syntactically correct and contains no LISP errors. 

The function examine is useful for inspecting the structure of DPL objects. The 
command 

(EXAMINE <object>) 

will place the user in an "examiner-loop" for examining the structure of <object>. He 

may type commands to identify the components of the structure he wishes to view. 

The examine function is system-dependent and will not be described in detail here. It 

^n is self-documenting -- typing "?" or "help" will print out the available options on the 
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j^\ system being used. 

9.2 What Objects Look Like 

When interacting with DPL it is necessary to know what the DPL structures look 
like when they are printed. The printed representations of DPL structures are for the 
user's convenience and have little to do with the way structures are stored in the 
computer. 

The printed appearance of types and prototypes will vary greatly among different 
implementations of DPL. In general, the examine function should be used to look at 
them. 

The function 

(TYPE-FROM-TYPE-NAME <type-name>) 

returns the type with the name <type-name>. 
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Components of the structure of a type or prototype may be inspected with the: 

(THE 'TYPE <'prototype>) 
(THE 'PROTOTYPES <type>) 

For the remainder of this chapter, we represent types by their names, and 
prototypes by the name of their type concatenated with a number. 

An instance contains a VC and a prototype: 

(INSTANCE (VC <prototype> <parent>) <augmentation>) 

The Augmentation) of an instance is a transform: 

(<unitary-part> <x> <y>) 

(or it may be nil which is the same as the "identity-transform," (identity o 0)). So a 
whole instance may look like this: 

(INSTANCE (VC INVERTER-5 REGISTER-12) (ROT90 34 10)) 

Since there are so many of them, prototypes of the type rectangle are treated 
differently from other prototypes. The only time this makes a difference is when they 
are printed out. In this case they look like: 

(RECTANGLE <layer> <length> <width>) 
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fs. <iength> is the Y dimension of the prototype and <width> is its X dimension. 

Rectangles are used in place of normal prototypes, so an instance of a rectangle 
could look like this: 

(INSTANCE (VC (RECTANGLE POLY 2 4) (IDENTITY 4 5))) 



9.3 CIF 

Users of DPL must interact with CIF for two reasons: Interesting cells from other 
designers are available in CIF, and CIF must be given to the fabrication companies to 
actually produce the chips. 

CIF descriptions of cells may be translated into DPL with the ciftran function. 
The form 

(CIFTRAN <cif-file> <load?> <output-f ile> <1ambda>) 

translates the CIF in <cif-f iie> into DPL in <output-f iie>. The argument <iambda> is 
the size of lambda in microns used to produce the CIF. If <ioad?> is not nil, the 
resultant DPL definitions are immediately loaded into the LISP environment and the 
types produced are available to call. All the arguments to ciftran are evaluated. 
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The DPL produced from CIF is extremely "bare". Nothing is named, for 
example, and thus none of the path-following features of DPL may be used. It is 
possible to edit the definitions of the types in the output from ciftran and name some 
of the parts. 

To obtain a CIF representation of a design, the function cifout is used. The form 
is: 

(CIFOUT <instance> <fi1e-name>) 
cifout takes an instance and recursively travels through the data-base, translating 
into CIF all the types on which < 1 nstance> depends. The final CIF command is a call to 
the symbol that corresponds to the prototype of < instanced "User extension 9" is 
used for the names of the prototypes as they are translated. The name of each type is 
included in a comment after the DS command. All the arguments to cifout are 
evaluated. 
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/-% 10. EXAMPLE 
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in this chapter we explain in detail a deflayout of a register cell. The program 
uses most of the features of DPL, so serves as a good illustration of the language in 
action. We have two reasons for presenting this example. First, the example should 
help the user learn how to use DPL. Second, we want to demonstrate some of the 
ways to use DPL to its best advantage. 

10.1 DPL design style 

The program below is one of many possible programs that could be written to lay 
out this cell. There certainly is no one place to start or one way to proceed in such a 
program. However, there are a number of guidelines to be kept in mind. 

Note that very few numbers are used in the program. Almost every new part is 
placed by reference to the locations of previously placed parts. Most of the spacings 
and offsets between parts are determined by the design rules of the processing 
technology. DPL provides variables to specify such values. 

It is helpful to begin at some point in the cell and move in a particular direction, 
creating new parts when their location may be described in terms of the existing 
structure. Specifying placement by reference to previously placed parts is 
encouraged because it makes apparent the justifications for the positioning of parts. 
Specifying placement numerically incorporates no information about why an object is 
placed where it is. On the other hand, a "symbolic" specification of position enables 
one to see, for example, that the end of a wire is to connect to the input of an inverter. 

Symbolic specification of a design contributes to easier debugging. Since all the 
parts depend in precise ways upon one another, moving an object will cause the parts 
specified in terms of it to maintain their distance. This ability is totally absent in a cell 
specified numerically, where each affected part would have to be moved. 
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10.2 TheREGCELL 

The object we are designing is meant to store a bit of data; it can be written from 
a bus and can write its value onto the bus. The circuit, shown in figure 9, consists of 
two inverters with a feedback path to refresh the data and connections to the data 
bus. During phi2 the value is refreshed. The cell is given a new value by placing the 
bit on the bus and taking the phil&load signal high. The value of the cell may be read 
onto the bus by taking phi 1 &read high. 

Figure 10 is a drawing of the cell's layout in NMOS technology. We have chosen 
the most straightforward design possible, to allow us to concentrate on using the 
language -- as opposed to a fancy layout. This layout is certainly not the smallest for 
this cell. We leave it as an exercise for the reader to come up with a "minimal" layout 
for this cell. 

On the next pages we present the definition of regcell. 



phil & load 



phi2 



phil & read 




Figure 9-- Circuit of Regcell 
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Figure 10-- The REGCELL 
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I (deflayout regcell f () 

f*S 2 (part 'ivl inline-inverter (ew 4)) 

3 (part 'GND-contactl square-contact (layer f diff) 

4 (top-center (>> center source-diffusion pulldown ivl))) 

5 (part 'VDD-contactl square-contact (layer * dif f ) 

6 (bottom-center (>> center drain-diffusion transistor pullup ivl))) 

7 (part 'be butting-contact (xfrm *rot!80)) 

8 (align (>> be) 

9 (>> apparent-bottom-right be) 

10 (Pt (- (>> x bottom-left contact pullup ivl) *metal-to-metal*) 

II (+ (>> y top-center GND-contactl) *metal -to-metal*) )) 

12 (wire () 

13 (run-layer 'poly) 

14 (from (>> apparent-bottom-center be)) 

15 (jog-y (>> center-left gate-poly pulldown ivl))) 

16 (wire 'phi2 

17 (run-layer 'poly) 

18 (from (pt ( + (>> x bottom-right gate-poly pulldown ivl) *poly-to-poly* 1) 

19 (>> y bottom-right GND-contactl))) 

20 (to-y (+ (>> y top-right VDD-contactl) 

21 *metal -to-metal* 

22 *def aul t-metal -size* 

23 *metal-to-metal*))) 

24 (part 'poly-contact square-contact (layer 'poly)) 

25 (align (>> poly-contact) 

26 (>> bottom-left poly-contact) 

27 (pt (+ (>> x center phi2) *poly-to-poly* 1) 

28 (+ (>> y top-right GND-contactl) *metal -to-metal*) ) ) 

29 (wire () 

30 (run-layer 'metal) 

31 (run-width *min-metal -size*) 

32 (from (pt-above (>> bottom-right cover contact pullup ivl) 

33 (// *min-metal-size* 2.0))) 
/*\ 34 (to-x (>> center poly-contact))) 

35 (part *iv2 inline-inverter) 

36 (align (>> iv2) 

37 (>> top-left gate-poly transistor pullup iv2) 
(pt " (+ (>> x top-right poly-contact) *poly-to-poly*) 

(>> y top-left gate-poly transistor pullup ivl))) 
(part 'GND-contact2 square-contact (layer 'diff) 

41 (top-center (>> center source-diffusion pulldown iv2))) 

42 (part 'VDD-contact2 square-contact (layer 'diff) 

43 (bottom-center (>> center drain-diffusion transistor pullup iv2))) 

44 (wire () 

45 (run-layer 'poly) 

46 (from (>> bottom-center poly-contact)) 

47 (jog-y (>> center-left gate-poly pulldown iv2))) 

48 (wire 'feedback 

49 (run-layer 'diff) 

50 (from (pt-above (>> bottom-right diff contact pullup iv2) 1)) 

51 (to-x (pt-to-right (>> center-right vdd-contact2) 

52 (+ *diff-to-diff* 1))) 

53 (to-y (pt-above (>> top-center vdd-contact2) 

54 (+ *metal-to-metal* 

55 (// *default-metal-size* 2.0)))) 

56 (save-cp 'read-turn) 

57 (to-x (>> apparent-top-center diff be)) 

58 (save-cp 'load-turn) 

59 (to-y (>> apparent-top-center diff be))) 

60 (wire 'phil&load 

61 (run-layer 'poly) 

62 (from (pt (~ (>> x apparent-bottom-left poly be) 

63 ( + *poly-to-poly* 1)) 

64 (>> y start phi2))) 

65 (to-y (>> y end phi2) )) 
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66 (wire 'phil&read 

67 (run-layer T poly) 

68 (from (pt (+ (>> x center-right feedback) 

69 (+ *poly-to~diff* 1)) 

70 (>> y start phi2))) 

71 (to-y (>> y end phi2) ) ) 

72 (part 'load-trans pass-transistor (xfrm 'rot90)) 

73 (align (>> load-trans) 

74 (>> center load-trans) 

75 (pt (>> x center phil&load) 

76 (>> y load-turn feedback))) 

77 (part 'load-contact square-contact 

78 (layer 'diff) 

79 (center-right (pt (- (>> x center phil&load) 

80 (+ *poly-to-diff* 1)) 

81 (>> y load-turn feedback)))) 

82 (wire () 

83 (run-layer 'diff) 

84 (from (>> load-turn feedback)) 

85 (to-x (>> apparent-center-right load-trans))) 

86 (part 'read-trans pass-transistor (xfrm 'rot90)) 

87 (align (>> read-trans) 

88 (>> center read-trans) 

89 (pt (>> x center phil&read) 

90 (>> y read-turn feedback))) 

91 (part 'read-contact square-contact 

92 (layer 'diff) 

93 (center-left (pt (+ (>> x center phil&read) 

94 (+ *poly-to-diff* 1)) 

95 (>> y read-turn feedback)))) 

96 (wire () 

97 (run-layer 'diff) 

98 (from (>> read-turn feedback)) 

^*\ 99 (to-x (>> apparent-center-left read-trans))) 

100 (wire 'data-bus 

101 (run-layer 'metal) 

102 (from (>> center-left load-contact)) 

103 (to-x (>> center-right read-contact))) 

104 (wire 'vdd-bus 

105 (run-layer 'metal) 

106 (from (pt (>> x start data-bus) 

107 (>> y center vdd-contactl) ) ) 

108 (to-x (>> end data-bus))) 

109 (wire 'gnd-bus 

110 (run-layer 'metal) 

111 (from (pt (>> x start data-bus) 

112 (>> y center gnd-contactl) ) ) 

113 (to-x (>> end data-bus))) 

114 (setq-my h-pitch (- (>> x center read-contact) 

115 (>> x center load-contact)))) 
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10.3 Discussion of the REGCELL program 

We have laid out regcell by beginning with the leftmost inverter, creating the 
parts surrounding it, and moving around the cell building each part as its position is 
determined by its neighbors. We built the central pieces of the cell first and built the 
busses extending the entire width of the cell last. The busses were built last so there 
would be objects by which to specify their dimensions. 

Let us look at the program in more detail. We begin with the leftmost inverter, 
which we name ivi, because it is a prominent piece of the cell and seems like a good 
place to start, ivi is created by using the part function which makes an instance of 
the prototype inline-inverter (see Library) with an enhancement channel width of 4. 
This will give the inverter a ratio of 8-1 which is necessary because it will be driven 
through a pass-transistor. The other parameters of inline-inverter will default as 
follows: The enhancement channel length will be 2, the depletion channel length 8, 
and the depletion channel width 2. (line 2) 

We may now create things whose locations depend on that of ivi. We create 
gnd-contacti and vdd-contacti placing them below and above ivi. They will be used 
later to connect the inverter to the power and ground busses, (lines 3 - 6) 

After making the two square contacts, we create the butting contact on the left 
of ivi, and call it bc. We rotate bc 180° because the untransformed butting contact 
has its diffusion on the bottom and we need it on the top. We then align bc the 
minimum metal-to-metal distance from the metal to its right and the same distance 
above the ground bus. We use gnd-contacti to find out the height of the bus. Note 
that it was necessary for us to create the square contacts before making bc in order to 
specify the Y coordinate of bc. Of course we could have aligned bc with a part of ivi, 
say making the apparent-bottom-right of the cut of bc 3 lambda to the left of the 
bottom-left of the contact of the pullup of ivi. While this would work fine, it doesn't 
really represent the reason that bc is placed where it is. The location of bc is 
determined to the right by the metal in ivi and below by the eventual location of the 
ground bus. The placement we use indicates these dependencies, (lines 7-11) 

We can finish up this segment of the cell by connecting a poly wire from the poly 
of butting contact bc to the gate -poly of the pulldown of ivi. The wire starts from the 
apparent-bottom-center of bc and does a jog-y to the center-left of the gate-poly of 
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the pulldown of ivi. The jog-y command here will actually create a rectangle of 1 
lambda in the Y direction and then a rectangle extending in the X direction. We use a 
jog here to allow us the flexibility of being able to raise bc at some point in the future 
without having to change the description of the poly wire. Since there is nothing 
requiring bc to be as close to the ground bus as we have made it, it is possible to move 
it higher if necessary, (lines 12-15) 

We now move to the right and create the clock line phi 2, the next object whose 
position is determined by those we have already built. Its position in the X direction is 
determined by the minimum poly-to-poly spacing from the pullup of ivi. We want the 
wire to run from the bottom of the cell to the top, plus one metal-to-metal distance at 
the top. The extra is so that several of these cells may be stacked to allow several bits 
to be stored at once. Since there will be a data-bus at the top of the cell, in addition to 
the power bus, we must allow room for one metal line of the default size, plus two 
metal-to-metal distances, (lines 16-23) 

Next we form the poly contact to the right of phi2. It can be no closer to ground 
than the minimum metal-to-metal distance and no closer to phi2 than the minimum 
poly-to-poly distance. We place it as close as it can get to these wires with an align 
procedure using these specifications. Next we run a metal wire from the bottom-right 
of the contact of the pullup of ivi to poly-contact. We make it 3 lambda (minimum 
metal width) wide. We must begin the wire 1.5 lambda above the bottom of the 
contact so that the connection will be 3 lambda wide. The to-x command then runs 
the wire to poly- contact, (lines 24 - 34) 

We are now ready to make our second inverter which we name IV2. We give it 
no parameters as we want its ratio to be 4-1 which is the default. The 4-1 ratio is 
justified because this inverter is driven directly from ivi. Its placement is determined 
on the left side by the minimum poly-to-poly distance from poly-contact. The vertical 
placement is to be the same as that for ivi. The power and ground contacts are then 
placed for IV2 in the same manner as for ivi. A poly wire from poly-contact to the 
gate-poly of pulldown of IV2 completes the connection of the output of ivi to the input 
of IV2. We again place the wire with a jog to allow us future flexibility, (lines 35 - 47) 

We will now construct the feedback path that refreshes ivi through pni2 and 
makes the connections to the data-bus through the control signals. The wire feedback 
runs from the diffusion in the contact of the pullup of IV2, to the right far enough to put 
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it one diff-to-diff distance away from vdd-contact2, then up to where the center of the 
data-bus will be. Two CPs of the wire, read-turn and load-turn, are saved for later 
placement of transistors, feedback then jogs to the diffusion in bc, completing the 
feedback path. Note that a transistor is created when the diffusion of feedback 
crosses the phi 2 wire, (lines 48 - 59) 

The control lines, phii&load and phii&read, may now be placed. Both are 
specified horizontally by minimum distances from existing structure and vertically by 
requiring that they begin and end at the same Y values as the start and end of PH12. 
(lines 60 -71) 

The connections from the feedback wire to the data-bus may now be made. The 
same procedure is used for the connections on the left and right sides of the cell. 
First a pass* transistor is placed at the appropriate position. Then a contact to the 
data-bus is created as close as possible to the control line. A wire is then run 
connecting the pass-transistor to one of the named CPs on feedback, (lines 72 - 99) 

All that remains is the busses. They extend from the left edge of load-contact to 
the right edge of read-contact. The Y coordinate of each bus has already been 
determined, (lines 100 - 113) 

The last command names the h-pitch of the cell. Note that the cell may be 
replicated so that the center of load-contact on one instance of regcell could line up 
with the center of read-contact on the instance to its left. We specify this here so that 
the constraints in the row replicator will place regcell correctly. We have designed 
regcell so that its vertical dimension is the correct one to use for replication so we 
need not specify it explicitly, (lines 114-115) 
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The definitions here are automatically loaded into the DPL environment. There 
will probably be other cells available. 



11.1 Some Constraints 



(defconstraint c= (vl v2) 
(vl (v2) v2) (v2 (vl) vl)) 



This causes the values of two 
parameters to be equal. 



(defconstraint c+ (vl v2 v3) 
(vl (v2 v3) (+ v2 v3)) 
(v2 (vl v3) (- vl v3)) 
(v3 (vl v2) (- vl v2))) 



The first value is to be the sum of the 
other two. 



/""N 



(defconstraint c* (prod ml m2) 
(prod (ml m2) (* ml m2)) 
(ml (prod m2) 

(if ( = m2 0) 
'bail-out 

(// (float prod) m2))) 
(m2 (prod ml) 
(if (= ml 0) 
'bail -out 
(// (float prod) ml)))) 



The first value is to be the product of 
the other two. 



(defconstraint offset (vl v2 v3) 
(vl (v2 v3) (pt-sum v2 v3)) 
(v2 (vl v3) (pt-difference vl v3)) 
(v3 (vl v2) (pt-difference vl v2))) 



All the values are points. The first 
point is to be the vector sum of the 
other two. 



11.2 Some Types 



(deflayout rectangle 

' ({primary- parameters 
((layer nil) 
(length nil) 
(width nil))) 
(constraints 

((default-size-for-layer layer length) 
(default-size-for-layer layer width))))) 



The structure of a rectangle is 
determined entirely by the values of 
its parameters. 
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^^ (deflayout square-contact 

^^ '((primary-parameters ((layer *poly)))) 

(part 'cut rectangle (layer 'cut)) 

(part 'cover rectangle (layer 'metal)) 

(part 'stuff rectangle (layer (>> layer)) 
(length 4) (width 4))) 

(deflayout horizontal-contact 

'((primary-parameters ((layer 'poly)))) 
(part 'cut rectangle (layer 'cut) 

(length 2) (width 4)) 
(part 'cover rectangle (layer 'metal) 

(length 4) (width 6)) 
(part 'stuff rectangle (layer (>> layer)) 
(length 4) (width 6))) 

(deflayout butting-contact '() 

(part 'cut rectangle (layer 'cut) 

(length 4)) 
(part 'cover rectangle (layer 'metal) 

(length 6)) 
(part 'poly rectangle (layer 'poly) 

(length 3) (width 4) (center (pt 1.5))) 
(part 'diff rectangle (layer ' dif f ) 

(length 4) (width 4) (center (pt -1)))) 

(deflayout rect-fet This is the standard transistor -- a 

'((primary-parameters rprtannnlar FFT 

((channel-length 2) rectangular ht I . 

fN (channel-width 2)))) 

(part 'gate-poly rectangle (layer 'poly) 

(length (>> channel-length)) 

(width (+ (>> channel-width) 

(* 2 *poly-overhang*)))) 
(part 'channel rectangle (layer 'channel) 

(length (>> channel-length)) 

(width (>> channel-width))) 
(part 'source-diffusion rectangle (layer 'diff) 

(length *diff-overhang*) 

(width (>> channel-width)) 

(top-center (>> bottom-center channel))) 
(part 'drain-diffusion rectangle (layer 'diff) 

(length *d if f-overhang*) 

(width (>> channel-width)) 

(bottom-center (>> top-center channel)))) 

(deflayout (rect-e-fet rect-fet) '()) A "rectangular enhancement FET" 

is the same as a "rect-fet". 
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(deflayout (rect-d-fet rect-fet) 

'() 

{part 'implant rectangle 
(layer 'ion) 
(length (+ (>> channel -length) 

(* 2 *ion~overhang*))) 
(width ( + (>> channel-width) 

(* 2 *ion-overhang*))) 
(center (>> center channel)))) 



A "rectangular depletion FET" has 
ion implant. 



(deflayout (pulldown rect-e-fet) f ()) 
(deflayout (pass-transistor rect-e-fet) '()) 



Both of these are alternate names 
for rect-e-fet. 



o. 



(deflayout standard-pullup 
' ( (primary- parameters 
((channel -length 8) 
(channel-width 2)))) 
(part 'transistor rect-d-fet 

(channel-length (>> channel -length) ) 
(channel-width (>> channel -width) ) ) 
(part 'contact butting-contact) 
(rot90 (>> contact)) 
(align (>> contact) 

(>> bottom-right cut contact) 
(>> bottom-center 

source-diffusion transistor)) 
(part 'poly rectangle 

(layer 'poly) (length 3) (width 2) 
(bottom-right 

(>> bottom-right poly contact))) 
(setq-my diffusion-connection 
(pt (» y 

bottom-left diff contact)))) 



A "standard pullup" has a contact 
on its left side and a connection 
from the contact to the gate of the 
transistor. 



(deflayout ( in! ine-pullup pullup) 
' ( (primary-parameters 
((channel -length 8) 
(channel-width 2)))) 
(part 'transistor rect-d-fet 
(channel-length 

(1+ (>> channel-length))) 
(channel-width (>> channel -width) ) ; 
(part 'contact butting-contact) 
(align (>> contact) 

(>> bottom-center poly contact) 
(>> bottom-center gate-poly transistor)) 
(setq-my diff us ion -connect ion 

(>> bottom-center contact))) 



An "inline pullup" has the butting 
contact directly below the transistor. 
The channel must be made one 
lambda longer than necessary for 
the correct ratio, because the 
contact will cover part of it. 
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[deflayout inverter 

1 ((primary-parameters 
((dl 8.0) (el 2.0) 
(ew 2.0) (dw 2.0) 
puz pdz z)) 
(constraints 
((c* dl puz dw) 
(c* el pdz ew) 
(c* puz z pdz)))) 
(part 'pullup standard-pullup 
(channel-length (>> dl)) 
(channel-width (>> dw))) 
(part 'pulldown rect-e-fet 

(channel-length (>> el)) 
(channel-width (>> ew))) 
(align (>> pulldown) 
(>> top-center 

drain-diffusion pulldown) 
(>> diffusion-connection pullup))) 



This inverter uses the standard 
puilup. Note the constraints 
between the parameter values and 
ratios. 
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(deflayout inline-inverter 
'((primary-parameters 
((dl 8.0) (el 2.0) 
(ew 2.0) (dw 2.0) 
puz pdz z)) 
(constraints 
((c* dl puz dw) 
(c* el pdz ew) 
(c* puz z pdz)))) 
(part 'pullup inl ine-pullup 

(channel-length (>> dl)) 
(channel-width (>> dw))) 
(part 'pulldown rect-e-fet 

(channel-length (>> el)) 
(channel-width (>> ew))) 
(align (>> pulldown) 

(>> top-center drain-diffusion pulldown) 
(pt-above (>> diffusion-connection pullup) 1))) 



This inverter uses the inline-pullup. 



11.3 Some Replicators 

These replications make use of the h-pitch and v-pitch constraints between 
their instance lists and their "pitch" parameters. The "pitch" of an instance is the 
minimum distance between points where successive replicated versions of the 
instance may be placed. In most cases this is the size of the instance in the 
appropriate dimension "H" (horizontal) or "V" (vertical). However, if a cell is explicitly 
given a parameter with one of these names, the value in that cell is used. 
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(def replicator row (i) 
' ((primary-parameters 

((pitch) (spacing 0))) 
(constraints 

((h-pitch instance-list pitch)))] 
( repl icator- instance 

(>> (*rep-instance 0))) 
(repl icator- transform 
' identity 

(* i (+ (>> pitch) (>> spacing))) 
0)) 



This places a row of objects. The 
spacing parameter may be used to 
insert extra space between the 
elements. 



(def replicator column (i) 
' ((primary-parameters 

((pitch) (spacing 0))) 
(constraints 

((v-pitch instance-list pitch)))) 
( repl icator- instance 

(>> (*rep-instance 0))) 
( repl icator-transform 

'identity 



(* i (+ (>> pitch) (>> spacing))))) 



Makes a column. 



A 



(def repl icator array (i j) 
• ((primary- parameters 
((v-pitch) (h-pitch) 
(v-spacing 0) (h-spacing 0))) 
(constraints 
((h-pitch instance-list h-pitch) 
(v-pitch instance-list v-pitch)))) 
(replicator-instance (>> (*rep-instance 0))) 
(repl icator-transform 
1 identity 
(* i (+ (>> h-pitch) (>> h-spacing))) 
(* j (+ (>> v-pitch) (>> v-spacing))))) 



This takes an instance and makes 
an n x m array of it. The pitches 
default as for row and column. 
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gjn, (def repl icator flipping-array (i j} 

r* '((primary -parameters 

(v-pitch h-pitch xref yref 
(x-overlap 0) (y-overlap 0) 
(x-space 0) (y-space 0))) 
(constraints 

((flipping-pitches 

instance-list h-pitch v-pitch xref yref 
x-overlap y-overlap x-space y-space)))) 
(let {(x ( i 2)) (y ( j 2)) which unitary) 
(setq which (+ x (* 2 y))) 

(setq unitary (cond ((equal which 0) 'identity) 
((equal which 1) 'negx) 
((equal which 2) 'negy) 
((equal which 3) f rotl80))) 
(replicator-instance (>> (*rep-instance 0))) 
(replicator-transform unitary 

(if (= x 0) 

(* (// i 2) (>> h-pitch)) 
(+ (>> xref) 
(* (// i 2) 

(>> h-pitch)) 
(- (>> x-overlap)))) 
(if (= y 0) 

(* (// j 2) (>> v-pitch)) 
(+ (>> yref) 
(* (// j 2) 

(>> v-pitch)) 
(- (» y-overlap))))))) 



—^ This makes an array in which 

* ' alternate elements are flipped. It 

uses a flipping-pitches constraint 
which is similar to the pitch 
constraints. One can make a row in 
which alternate elements are flipped 
by calling flipping-array with a 
second argument of 1, or a column 
of alternately flipped elements by 
using a first argument of 1. 
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^ 12. GLOSSARY 

Presented here are most of the DPL functions and variables available for 
designing projects. Functions which are used only for the implementation of the 
language are not included. 

Each function is presented with information about the arguments it takes. For 
example 

(A-FUNCTION <arg-l> '<arg~2> . <form-l> <form-2> . . .) 

introduces the function a-function. Arguments are enclosed in angle brackets (<>) 
and are given reasonably mnemonic names. Arguments not evaluated are shown with 
a quote before them, (like <arg-2> above). A dot (.) in the form indicates that the 
terms after the dot are optional and thus may be omitted. Three dots (. . .) at the end 
of some optional arguments indicates that there may be any number of terms in the 
argument list at that point. 

f\ Every term in the body of a form will be described. In some cases the terms 

themselves must be structured in certain ways. 

The functions will be grouped according to the kinds of DPL objects they 
operate on -- transform functions are grouped together, as are functions that 
manipulate points. 
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12.1 Types 



(DEFLAYOUT '<type-name> 
<param-1ist> 
. f <body>) 



Defines a type. If <type-name> is an 
atom, the new type will have that 
name. If the name is a list of two 
atoms, the car will be the name of 
the new type, the cadr will be used 
as the "supertype" of the type. 

<param-1ist> is a list of 

keyword-value pairs. The value of 
each pair is stored in a cellon the 
type. <body> is the maker function of 
the type and may consist of any LISP 
and DPL forms. 
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(PRIMARY-PARAMETERS 

((<param-name-l> <defauU-value-l>) 
(<param-namo-2> <defauU-va1ue-2>) 

• • 0) 



(CONSTRAINTS 

((<constraint-name <param> <param> . 
(<constraint-name <param> <param> . 

. . .)) 



(AUXILIARY-PARAMETERS 

(<param-name>. . .)) 



This form in the <param-iist> of a 
deflayout specifies the names and 
default values for the parameters 
used to build instances of the type. 

This form in the <param-"iist> of a 
•j deflayout specifies that the 
constraints named are to be applied 
to the parameters named. 

This form in the <param-iist> of a 
deflayout specifies some of the 
names used by the maker function 
to store information. 



(TYPE-FROM-TYPE-NAME <type-name>) 



(TYPE? <object>) 



Returns the type whose name is 

<type-name>. 

Tests to see if <object> is a type. 



(PART <name> '<type> 

. <param-l> <param-2> . . .) 



Creates an instance of <type> and 
makes it a part of *me*. If <name> is 
non-NiL, it is used as the name of the 
part on *me*. Each of the 
parameters has the following form: 
( '<param-name> <value>) 

The (<param-name>) may be a 
defined parameter of the type, an 
"implicit-parameter" , or parameters 
used to place the instance. 
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(DELETE-INSTANCE <instance>) 



Removes <instance> from the parts 

Of *ME*. 



(INVOKE <name> '<type> 

♦ . <param-l> <param-2> 



Identical to part except that the 
instance produced is not 

considered to be a "part" of *me*. 



(REMTYPE <typo-name>) 



Removes all prototypes and 
instances of the type and all 
prototypes and instances that use 
them. The type definition is still 
available. 



(DESTROY-TYPE <typo-name>) 



Does a remtype of the type and then 
removes the type from the list of 
defined types. The type may then no 
longer be called. 



12.2 Naming 
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(ASSIGN-TO-THE <name> <object> <value>) 



(SET-MY <name> <value>) 



(SETQ-MY '<name> <value>) 



(BOUND-ON? <name> <object>) 



Creates a cell named <name> on 
<ot>ject> and places <vaiue> in it. 

Creates a cell named <name> on *me* 
and places <vaiue> in it. 

The same as set -my but <name> is not 
evaluated. 

Tests to see if a cell named <name> 
exists on <object>. 



fs 
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12.3 Access Functions 



(THE <name> <object>) 



Finds the value of <name> in <object>. 
If the value is a transformable object, 
the appropriate composition of 
transforms is performed to assure 
that the result is viewed in the 
correct coordinate system. <name> 
may be the name of information 
placed by deflayout, setq-my, an 
"implicit-parameter", or one of the 
components of a DPL structure (for 
example, the prototype of an 
instance). 



(» . <form-l> <form-2> . . .<form-n>) 



r\. 



Expands into a series of calls to the. 
The <object> of the last call to the is 
*me*. Accesses information from 
*me* as well as information nested in 
parts of *me*. If the forms are atoms 
they are not evaluated. Otherwise 
they are evaluated and the results 
used as the names. 



(E» <atom>) 



Returns <atom>. It is used if one 
wants to evaluate an atom in a >> 
form. 



(MY <name>) 
(EXAMINE <thing>) 



The same as: (the <name> *me*). 

Used to interactively examine the 
components of the structure of 
<thing>. Allows the user to indicate 
the parts he wishes to examine. The 
command quit exits the program, ? 
prints documentation. 
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12.4 Points 



(PT <x> <y>) 



(PT? <object>) 



Makes a point with the given 
coordinates. 

Tests the object to see if it is a point. 



(PT-SUM <ptl> <pt2>) 
(PT-DIFFERENCE <ptl> <pt2>) 



(PT-ABOVE <pt> <offset>) 
(PT-BELOW <pt> <offset>) 
(PT-TO-LEFT <pt> <offset>) 
(PT-TO-RIGHT <pt> <offset>) 



These functions create a point that 
is the vector sum or difference of the 
two arguments. 

These functions create a point offset 
from the given point the specified 
amount in the specified direction. 



12.5 Transform Functions 
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(<unitary-transform> <instance>) 



Applies the unitary transform 
function to the instance. This gives 
the instance a new transform which 
is the composition of the 
unitary-transform with the previous 
transform of the instance. 



IDENTITY 
R0T180 
NEGX 
INT-POS 



R0T90 
ROT270 
NEGY 
INT-NEG 



These are the unitary transform 
functions. Their names may be used 
as the xfrm parameter in a part 
command. The names may also 
appear as the unitary-part of a 
transform. 



(ALIGN <instance> 

<pt-on-instance> 
<target-pt>) 



(SET-TRANSFORM <instance> <transform>) 



(TRANSFORM-PT <transform> <pt>) 



Translates the instance so that 

<pt-on-instance> is at 
<target-pt>, 

Gives the instance a transform of 
<transform>. 

Returns the point that is the result of 
transforming <pt> by the 

<transform>. 
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(TRANSFORM-PT-BY-UNITARY 

<unitary-transform> <pt>) 



(CREATE-TRANSFORM <unitary-part> <pt>) 



The same as transform-pt but the 
argument is the name of a 
unitary-transform function. 

Creates and returns a transform with 
the given unitary-part and a 
translation part determined from 
<pt>. 



(COMPOSE-TRANSFORMS <trans-l> <trans-2>) 



The transform that is returned is the 
result of first applying <trans-2>, 
then <trans-l>. 



(COMPOSE-UNITARY-TRANSFORMS <ut-l> <ut-2>) 



Gives the unitary-transform that 
results from applying unitary 
transform <ut~2> followed by unitary 
transform <ut~i>. 



{INVERSE-TRANSFORM <transform>) 



Returns the transform that, when 
composed with <transform>, would 
give the identity transform. 
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( INVERSE-UNITARY-TRANSFORM 
<unitary-transform>) 



The same as inverse-transform 
except that this takes and returns a 
unitary transform. 
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12.6 Wiring Commands 



(WIRE <name> ♦ <body>) 



Makes a wire and names it <name> if 
the name is non-NiL. <body> is then 
executed with the wire bound to the 
variable *the-wire*. <body> may 
contain and LISP forms or special 
wire procedures. 



(RUN-LAYER <layer>) 
(RUN-WIDTH <va1ue>) 
(FROM <1ocation>) 
(TO-X <1ocation>) 
(TO-Y <location>) 
(TO-PT <1ocat1on>) 
(JOG-X <pt>) 
(JOG-Y <pt>) 
(+X <value>) 
(-X <value>) 
(+Y <va1ue>) 
(-Y <value>) 
(SAVE-CP <name>) 
(RESTORE-CP <name>) 
(DROP-CONTACT) 



These commands are allowed inside 
a wire form. All of these have 
corresponding functions for use 
from "outside" the wire. Their 
names are wiRE-<name> where the 
<name> is one of the above. 



^ 



(PT-CP <cp>) 



Gets the point 
connection-point. 



from the 



12.7 Constraints 



(DEFCONSTRAINT *<nam8> 
'<var-1ist> 
• *<body>) 



Defines a constraint named <name>. 
When called, the constraint will bind 
whatever variables in <var-iist> are 
specified. Then the <body> will be 
executed. The forms in the body 
look like: 
(<resuft-var> <depends-on> <code>) 

(None of these are evaluated when 
the def layout is evaluated.) The 
<resuit-var> is the variable that may 
be computed if all the variables in 
the <depends-on> list are specified. 
The procedure to find the value of 
that variable is specified by <code>. 
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(DEFDEFAULT *<name> 
•<vap-Tist> 
• *<body>) 



Defines a "default" constraint. The 
constraint will be effective only if no 
other attempt is made to set the 
value of the parameters it 
constrains, either by explicit passing 
of values or other "normal" 
constraints. Form and use are 
identical to defconstraint. 



12.8 Replicators 



(DEFREPLICATOR '<name> 

, <coordinate-variab1es> 
<param-list> 
. <body>) 



Defines a replicator. The <name> and 
<param-iist> work the same as for 

DEFLAYOUT. <coordinate-variables> 

is a list of names that are used in 
<body> to compute the instance at 
the corresponding coordinates 
when the replicator is referenced. 



(*REP <1> <j>) 
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Used in a the or >> command, gets 
the (<i>,<j>)-th element of a 
replication. 



(*REP-INSTANCE <n>) 



(REPLICATOR-INSTANCE <instance>) 



Gets the nth instance in the 
instance-list of the replication. 

Must appear in the body of a 
replicator. Indicates the instance 
that is to be returned when the 
replicator is accessed. Usually 

<instance> is a Call to *REP-INSTANCE 

that depends on the 

<coordinate-variables> of the 
replicator. 



(REPLICATOR-TRANSFORM 

<unitary-part> <x> <y>) 



Must appear in the body of a 
replicator. Indicates the transform 
that is to be composed with the 
transform of the instance given to 

REPLICATOR-INSTANCE. 



^\ 



GLOSSARY 



•79 



DPL Manual 



r^ 



(REPLICATE <name> f <replication> 
<coordinatG-sizes> 
. <param-list>) 



Calls the replicator <repiication>. 
The list <coordinate-sizes> gives the 
values of the dimensions of the 
coordinates. The rest of the form is 
identical with the part form. 



12.9 CIF 

(CIFOUT <instance> <filename>) 



Outputs CIF translations of enough 
of the data-base to build the 
instance. 



(CIFTRAN <f11e> 

<1oad?> <fi1e-out> <1ambda-$ize>) 



Translates the CIF in the <nie> into 
DPL and places the result in the file 

<f ile-out>. The < lambda-size> is the 

size of lambda in microns with which 
the original CIF was produced. If 
<ioad?> is non-NiL, the DPL forms 
are loaded into the current 
environment. 
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12.10 Implicit-Parameters 



BOUNDING-BOX 

XDIM 

TOP-LEFT 

CENTER-LEFT 

BOTTOM-LEFT 

TOP-CENTER 

CENTER 

ORIGIN 



YDIM 

TOP-RIGHT 

CENTER-RIGHT 

BOTTOM-RIGHT 

BOTTOM-CENTER 



The implicit parameters of an 
instance. All (except bounding-box) 
have corresponding apparemt- 
versions. 



12.11 *L!ST* 



(MAKE-LIST-OF <list>) 



Makes a *list* from the list. Used 
when the list will contain 
transformable objects. 
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(THE-LIST-OF <1ist>) 



Extracts the list from a *list* 



12.12 LayerSizing 



(LAYER-DEFAULT-SIZE <layer>) 



Finds the default size for the layer. 
Uses the "default-size" constants 
below. 



(LAYER-MINIMUM-SIZE Oayer>) 



Finds the minimum size for the layer. 
Uses the "minimum-size" constants 
below. 



12.13 Symbols 
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♦ME* 



When prototype is being 

constructed by the maker function 
of a type, *me* is bound to that 
prototype. Otherwise, *me* is bound 
to the "top". 



♦THE-WIRE* 



*CURRENT-WIRE* 



(♦UNNASIGNED*) 



Bound to the wire being constructed 
in a wire form. 

Used to access CPs of the wire 
being constructed. 

This list is placed in cells between 
the time they were created and the 
time they get values. If it is ever 
seen, it means that an error has 
occurred - somehow a cell has 
been accessed that has no value. 



♦TYPE-LIST* 



Contains a list of the names of all 
defined types. 
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12.14 Constants 

All these numbers are in lambda. They depend on the design rules of the 
process being used. 
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♦MIN-POLY-SIZE* 


2 


♦MIN-CHANNEL-SIZE* 


2 


♦MIN-DIFF-SIZE* 


2 


♦MIN-METAL-SIZE* 


3 


♦MIN-CUT-SIZE* 


2 


*MIN-ION-SIZE* 


5 


♦MIN-NOGLASS-SIZE* 


2 


♦DEFAULT-POLY-SIZE* 


2 


♦DEFAULT-CHANNEL-SIZE* 


2 


♦DEFAULT-DIFF-SIZE* 


2 


♦DEFAULT-METAL-SIZE* 


4 


♦DEFAULT-CUT-SIZE* 


2 


♦DEFAULT-ION-SIZE* 


5 


♦DEFAULT-NOGLASS-SIZE* 


2 


♦POLY-OVERHANG* 


2 


♦DIFF-OVERHANG* 


2 


♦ION-OVERHANG* 


1.6 


♦METAL-TO-METAL* 


3 


♦POLY-TO-POLY* 


2 


♦DIFF-TO-DIFF* 


3 


♦POLY-TO-DIFF* 


1 


♦ION-TO-TRANSISTOR^ 


1.5 



The minimum-size constants. 



The default-size constants. 



Other useful numbers. 



